Pull Request Test Coverage Report for Build 408595900

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.03%) to 96.806%

Totals
Change from base Build 396793693:	-0.03%
Covered Lines:	485
Relevant Lines:	501

💛 - Coveralls

Thanks @eregon. I hadn't seen that note in the setup-ruby action. Hopefully I can find some time to experiment with it.

I left truffleruby commented out because I was wondering about the usefulness of Better Errors in that runtime. Without binding_of_caller, there's not much functionality. We also don't run our tests on JRuby or Rubinius for the same reason. Do you see a real usefulness to Better Errors on truffleruby?

Finally, since there's no released version of truffleruby we can run against, it seems like a real possibility that our tests will fail against the "head" on a arbitrary days. Since there's no "allow failure" setting in Github Actions, this would result in a failed build for reasons unrelated to the changed made to the local project. (This is why I left ruby-head out of the matrix.) So I would prefer to wait until there's a stable release that we can build on so that we can be sure of the reliability in CI.

I left truffleruby commented out because I was wondering about the usefulness of Better Errors in that runtime. Without binding_of_caller, there's not much functionality.

We'll probably add support for binding_of_caller at some point, I don't think there is any fundamental issue to implement that, just need to take the time for it. Although, binding_of_caller looks quite dependent on MRI internals, so probably it'd need a new backend.
https://github.com/banister/debug_inspector seems a newer alternative, and we're working on implementing that C API in TruffleRuby.

Do you see a real usefulness to Better Errors on truffleruby?

It is useful to detect any potential incompatibility in TruffleRuby.
I actually check if it passes with https://github.com/eregon/truffleruby-gem-tracker/actions, and that's also how I noticed it was removed during the migration to GitHub Actions.
The jobs added here, and which were running in TravisCI previously are passing, I don't think they failed except as a cause of updating to Ruby 2.7 and so having to exclude tests on Rails 4.